The present invention relates to the field of computers and particularly to computers having central processing units (CPU's) that operate in accordance with the IBM ESA/390 architecture and particularly to computers that have means for accessing and purging an Access Register Translation Lookaside Buffer (ALB).
ESA/390 architecture computers are controlled by a Program Status Word (PSW). The program-status word (PSW) includes the instruction address, condition code, and other information used to control instruction sequencing and to determine the state of the computer. The active or controlling PSW is called the current PSW. It governs the program currently being executed.
The CPU has an interruption capability, which permits the CPU to switch rapidly to another program in response to exception conditions and external stimuli. When an interruption occurs, the CPU places the current PSW in an assigned storage location, called the old-PSW location, for the particular class of interruption. The CPU fetches a new PSW from a second assigned storage location. This new PSW determines the next program to be executed. When it has finished processing the interruption, the interrupting program may reload the old PSW, making it again the current PSW, so that the interrupted program can continue.
The status of the CPU can be changed by loading a new PSW or part of a PSW. Control is switched during an interruption of the CPU by storing the current PSW, so as to preserve the status of the CPU, and then loading a new PSW.
A new or modified PSW becomes active (that is, the information introduced into the current PSW assumes control over the CPU) when the interruption or the execution of an instruction that changes the PSW is completed.
A storage key is associated with each 4K-byte block of storage that is available in the configuration. The storage key has the following format. ##STR1## The bit positions in the storage key are allocated as follows: Access-Control Bits (ACC)
If a reference is subject to key-controlled protection, the four access-control bits, bits 0-3, are matched with the four-bit access key when information is stored, or when information is fetched from a location that is protected against fetching.
Fetch-Protection Bit (F)
If a reference is subject to key-controlled protection, the fetched protection bit, bit 4, controls whether key-controlled protection applies to fetch-type references are monitored and that fetching with any access key is permitted; a one indicates that key-controlled protection applied to both fetching and storing. No distinction is made between the fetching of instructions and of operands.
Reference Bit (R)
The reference bit, bit 5 normally is set to one each time a location in the corresponding storage block is referred to either for storing or for fetching of information.
Change bit (C)
The change bit, bit 6, is set to one each time information is stored at a location in the corresponding storage block.
Protection
Protection facilities are provided to protect the contents of main storage from destruction or misuse by programs that contain errors or are unauthorized. Key-controlled protection, access-list-controlled protection, page protection, and low-address protection are forms of protection available in ESA/390.
Key-Controlled Protection
When key-controlled protection applies to a storage access, a store is permitted only when the storage key matches the access key associated with the request for storage access; a fetch is permitted when the keys match or when the fetch-protection bit of the storage key is zero.
The keys are said to match when the four access-control bits of the storage key are equal to the access key, or when the access key is zero.
Fetch-Protection-Override Control
Bit 6 of control register 0 is the fetch-protection-override control. When the bit is one, fetch protection is ignored for locations at effective addresses 0-2047. An effective address is the address which exists before any transformation by dynamic address translation or prefixing. However, fetch protection is not ignored if the effective address is subject to dynamic address translation and the private-space control, bit 23, is one in the segment-table designation used in the translation.
Fetch protection override has no effect on accesses which are not subject to key-controlled protected.
Access-List-Controlled Protection
In the access-register mode, bit 6 of the access-list entry, the fetch-only bit, controls which types of operand references are permitted to the address space specified by the access-list entry. When the entry is used in the access-register-translation part of a reference and bit 6 is zero, both fetch-type and store-type references are permitted, and an attempt to store causes a protection exception to be recognized and the execution of the instruction to be suppressed.
Page Protection
The page-protection facility controls access to virtual storage by using the page-protection bit in each page-table entry. It provides protection against improper storing.
One of the instructions that is able to modify part of a PSW is the Set PSW Key From Address (SPKA) instruction. The ESA/390 architecture requires the SPKA instruction to load the architecturally defined PSW "access key" from four bits extracted from the effective address of the SPKA instruction. The access key is used to limit the access of future instructions to certain storage areas to aid in providing protection and privacy of information.
In the problem state, the execution of the SPKA instruction is subject to control by the PSW-key mask in control register 3. When the bit in the PSW-key mask corresponding to the PSW-key value is set is one, the SPKA instruction is executed successfully. When the selected bit in the PSW-key mask is zero, a privileged-operation exception is recognized. In the supervisor state, any value for the PSW key is valid. During execution of the SPKA instruction, the Condition Code remains unchanged.
The format of the SPKA instruction permits the program to set the PSW key either from the general register designated by the B.sup.2 field or from the D.sup.2 field in the instruction itself.
When one program requests another program to access a location designated by the requesting program, the SPKA instruction can be used by the called program to verify that the requesting program is authorized to make this access, provided the storage location of the called program is not protected against fetching. The called program can perform the verification by replacing the PSW key with the requesting-program PSW key before making the access and subsequently restoring the called-program PSW key to its original value. Caution must be exercised, however, in handling any resulting protection exceptions since such exceptions may cause the operation to be terminated.
One well-known computer operating with the IBM ESA/390 architecture is the Amdahl 5995-A computer. In that computer, the I-Unit pipeline is a six stage pipeline consisting of stages D, A, T, B, X, and W that process instructions.
One of the functions of the D stage is to collate the necessary information to reference storage in the A, T, and B stages. This D-stage function includes the generation of the effective address and selection of the access key to be used by the reference. The A, T, and B stages fetch operands/data using the current valid key that is defined by the architecture, PSW KEY.sub.A.
One of the functions of the W (write) stage is to write results of operations to architecturally defined registers or storage. The W stage in the pipeline comes after the fetch-operands/data stages (A, T, and B) and the arithmetic functions stage (X). The access key used is the key, PSW KEY.sub.A, from the architecturally defined PSW register. After the access key in the PSW has been updated in the W stage, the new key, PSW.sub.N, is available for future operations/instructions and the new key becomes the architecturally defined key, PSW KEY.sub.A. The ESA/390 architecture requires that the new key be effective starting from the instruction immediately following the SPKA instruction. The new PSW key can be used in a subsequent D segment while being updated in the W segment.
The fetching of any instruction following a SPKA instruction is subject to key fetch protection and hence must wait until the SPKA instruction has updated the key in the PSW register.
If a storage-reference instruction (an instruction that references storage) immediately follows a SPKA instruction, the fetching of data by that storage-reference instruction must wait until after the SPKA instruction has updated the access key in the PSW register, that is, must wait until the architecturally defined key, PSW KEY.sub.A, has been updated with the new value, PSW.sub.N, from the SPKA instruction.
In computer systems, a system control program (SCP) is responsible for resource management and often uses architectural registers. Computer systems under control of the control program operate in User State and in Control State. In User State, user programs and vendor-provided operating systems execute. IBM system control programs (CP's) run in User State. Certain instructions and facilities of User State may be emulated by Control State software.
Control State is for controlling system resources and they may be shared by multiple domains and provide emulation when necessary. Emulation may be used for enhancing the IBM ESA/390 architecture or may be used so that User State programs that run on one manufacturer's machines having one set of hardware may run on another manufacturer's machines with different hardware. Control State operation is based on the IBM ESA/390 architecture. Entry to Control State from User State is vectored, invoked by Control Interceptions that require assistance by Control State software.
Transitions from User State to Control State occur under a number of conditions. For example, a transition may occur when an instruction occurs that is defined as an emulated instruction when an instruction occurs for which a specific interception control is set, when an interruption occurs for which a specific interception control is set, when an interruption occurs that is defined as a mandatory Control Interception.
The SCP in some environments operates the machine hardware and multiplexes the physical resources of the computing system into multiple logical entities called virtual machines, each of which is a simulation of a computer dedicated to the servicing of a single user or (in the case of a server) a single application. Virtual machines are software entities that can be easily configured to running a particular program rather than to a user. A virtual machine configured in this manner is referred to as a virtual machine server. By virtualizing, operating systems can link guest systems together without the need for guest-specific actual hardware. Also, operating systems allow multiple guest systems to share devices and other resources to simplify configuration and maintenance.
Resource management (SCP) and user management (CMS) are separate. When a CMS user logs on to the system, the SCP (system control program) creates a virtual machine for that user that includes, among other things, storage address space. An address space is a sequence of addresses that starts at one address and extends up to a value that varies according to size. Storage management is an important task of the supervisor or host which must create, share, and otherwise manage address spaces, gain and relinquish access to an address spaces, and map data on external devices.
Virtual machines running in the ESA/390 architecture have at least one address space, the primary address space, given to the user by the SCP when the user logs on to the system. The size of this address space is determined from the entry describing that user in the user directory, or from a subsequent DEFINE STORAGE command. After logging on, if authorized in the user directory, a user may create other address spaces and share them with other logged-on users.
Before a program can actually read or write data in a nonprimary address space, it must invoke an SCP service to add an entry designating that address space to its access list. Each virtual configuration has its own access list having entries that determine which address spaces the virtual CPUs in that configuration can reference at any one time. The number of entries in the access list is controlled by information in the user's directory entry.
When a program adds an address space to its access list, SCP selects an unused entry in the access list, fills it in as requested by the program, and returns a four-byte access-list-entry token (ALET) to the program. A program uses this ALET to make direct references to the address space. The access-list entry thus allocated remains allocated until the program explicitly removes the entry, or until the virtual machine goes through a virtual- machine-reset operation.
Interpretive-Execution
The IBM Interpretive Execution Facility (IEF) allows a computer system running under a host System Control Program (SCP) to interpret a virtual machine called the guest. The term "host" refers to the real machine together with the SCP running on the real machine. The host manages real-machine resources and provide services to the guest programs which execute in an interpreted machine. The interpreted and host machines execute guest and host programs, respectively. For a transfer of control from a guest virtual machine back to its host System Control Program (SCP), an "interception" occurs.
In the existing computer architecture, when a guest issues a START INTERPRETIVE EXECUTION (SIE) instruction, the instruction is intercepted and emulated by the host program at a significant performance cost. Through emulation, the host provides the functions of a selected architecture which may be available on some other real machine or which may be available only in the virtual-machine environment. Privileged and problem-program instruction execution, address translation, interruption handling, timing and other functions are interpreted so that those functions are executed in the context of the virtual machine. With the addition of special-purpose hardware, interpreted execution can approach speeds that are comparable to native-mode execution, that is, execution by a non-interpretive version of the architecture.
In the virtual-machine environment, the guest program has access to all the functions defined for the designated architecture either through an interpretive-execution facility or by the host system control program. For VM/ESA, the control program CP provides functions through simulation. Simulation generally executes guest functions transparently so that the guest program is unaware as to whether a function is performed by the machine or the host except that simulation usually requires more time.
When an SIE instruction is executed, the operand of the SIE instruction containing the State Description is fetched to obtain information about the current state of the guest. When execution of SIE ends, information representing the state of the guest, including the guest program status word (PSW), is saved in the state description before control is returned to the host. The information in the state description, as used and modified by the host during simulation, allows the guest to start and stop execution with valid information. The state description also determines the mode and other environmental conditions in which the guest is to execute.
While in interpretive-execution mode the host, in order to be protected from interference by guests or interference among guests, allocates portions of the real-machine resources to the virtual machine. Guest storage is confined to a portion of host real storage or to host virtual address spaces controlled by the host system. Host enabled and disabled states generally are undisturbed by execution of the guest. A complete and logically separate set of control registers is maintained by the machine for use by the host and another set for each guest is maintained for use by the guest. Other registers are shared between the host and guests.
In some cases, the host intercepts operations normally performed by the machine. The state description includes control bits settable by the host to cause intercept operations under specific conditions. When the specific condition are met, the machine returns control to host simulation. Intervention controls capture the introduction of an enabled state into the PSW, so that the host can present an interruption which it holds pending for the guest. Intervention controls may be set asynchronously by the host on another real processor while interpretation proceeds. The machine periodically refetches the controls from storage, so that updated values will be recognized. Guest interruptions can thereby be made pending without prematurely disturbing interpretation.
Guest Storage
Preferred-storage mode and pageable-storage mode are provided for in the interpretive-execution architecture. In preferred-storage mode, a contiguous block of host absolute storage is assigned to the guest and in pageable-storage mode, dynamic address translation (DAT) at the host level is used to map guest main storage. In preferred-storage mode, the lower addresses of the machine storage are dedicated to the guest and only one guest can obtain production mode performance.
In the pageable-storage mode, the host has the ability to scatter the real storage of pageable-storage-mode guests to usable frames anywhere in host real storage by using the host DAT, and to page guest data out to auxiliary storage. This method provides flexibility when allocating real-machine resources while preserving the expected appearance of a contiguous range of absolute storage for the guest.
A virtual-machine environment may require DAT twice, once at guest level, to translate a guest virtual address into a guest real address, and then, for a pageable guest, at the host level, to translate the corresponding host virtual address to a host real address.
Multiple High-performance Guests
The Multiple Domain Facility.TM. (MDF.TM.) available on Amdahl computers provided concurrent execution of two or more operating systems with high performance on a single shared central computing complex. Such operation permits the reassignment of resources dynamically with minimal performance penalty for a variety of different architectures or systems.
Access Registers
The IBM ESA/390 architecture defines access registers that allow a problem-state program to refer to data in multiple address spaces concurrently, without supervisor intervention. The access registers provide a method to move data between two address spaces. They also allow the use of the complete instruction set to operate on data in multiple address spaces.
In the computer system, the base (B) field or register (R) field of an instruction designates a general register. In the access-register mode, the same-numbered access register is used during access-register translation (ART) to determine the address space of the operand.
Access-register translation uses an access-list-entry token (ALET) in an access register to derive the segmenttable designation (STD) to be used during dynamic address translation (DAT). The STD corresponds to an address space.
Access registers are also available to a guest in ESA/390 mode. The host is responsible for loading the guest's access-register values before starting interpretive execution, and for saving them (and restoring host values) afterward. The guest operating system must build the guest virtual address spaces and associated control structures, just as it would natively. Pages in these address spaces may be mapped to areas of guest main storage or paged by the guest supervisor to auxiliary storage.
In the ESA/390 Principles of Operation, the Access Register Translation (ART) process normally involves a two-level table lookup operation to access a Segment Table Designator (STD) to be used for virtual address translation, thereby specifying a virtual address space. The STD is then used in another two-level table lookup operation to translate the virtual address to a real address, as part of the Dynamic Address Translation process, or DAT.
This two-level lookup for DAT normally must be performed at every virtual access of storage, and therefore is very costly in terms of overall processor performance. The IBM architecture describes a Translation Lookaside Buffer (TLB) mechanism which keeps track of the most recently used virtual-to-real address translations and makes the results available for use by the processor logic at storage access time, avoiding the need to spend processor cycles on the DAT process.
The ALB is similar in both structure and concept to the TLB and is intended to provide the same performance enhancement to the ART process that the TLB provides for the DAT process.
A single ALB is physically implemented in each processor. However, multiple Logical Processors (LPs) can run on a given processor and therefore, whenever a switch is made on the physical processor between LP's currently running on the processor, the physical ALB normally requires a logical purge of all entries created up to the point of the context switch in order to insure that the entries in the ALB are logically consistent with the environment of the currently running LP. Because the physical processor is time-shared by many LPs, if this physical purge of the ALB is performed at each context switch, the performance gain provided by the ALB is eliminated since no logical entries created by a given LP would survive a context switch to another LP. If the original LP was redispatched, there would be no valid entries in the ALB, and ART would have to be reinvoked to create them, only to be lost again at the next context switch.
Host Access-Register Translation
When an access register contains a value other than zero and the guest is in access-register mode, the operand address specified refers to data in a host AR-specified address space. The contents of the base register together with the displacement and the index register, if applicable, are used to determine the offset of the data within the address space.
To resolve the address space of the operand, host access-register translation (host ART) is applied. Host access-register translation is similar to the access-register-translation process used in ESA/390 mode. Host ART uses an access-list-entry token in an access register to obtain the segment-table designation (STD) to be used during host dynamic address translation. 2 shows a flow chart of the host ART process.
During host ART, the designated access register contains an access-list-entry token. This token, which is obtained using VM/ESA services, has an access-list-entry number.
The origin of the primary address-space number (ASN) second-table entry (primary ASTE) is obtained from a host control register. An ASTE is associated with each address space and has the same format in VM Data Spaces as in ESA/390. The primary ASTE contains the origin of the access list used during the host access-register translation (host ART). An ASTE is also used later in the host ART process.
An access list contains entries which represent the addressing capabilities of the guest. The access-list-entry number in the access register together with the access-list origin in the primary ASTE determine the access-list entry to be used during host ART.
An access-list entry contains the address of an ASN second-table entry (ASTE). When an ASTE is located by an access-list entry, it is referred to as an access-list-specified ASTE, to distinguish this use of the ASTE from the primary ASTE described earlier. The access-list-specified ASTE contains the STD to be used during host DAT.
It is desirable to provide a mechanism to preserve as many entries created by an LP in the ALB as possible across context switches. If entries can be uniquely associated with the LP that created them, then no purging is necessary at context switch time and entries created by a given LP can be preserved across the context switch. When a PALB instruction is issued by the LP, only the entries associated with that LP need to be physically purged in order to give the ALB the appearance of being logically purged as seen by the LP.
Although such a mechanism preserves ALB integrity for various LP's across context switches, it necessitates the implementation of a hardware search machine which can sequentially examine each entry in the ALB, determine if it is associated with the currently-running LP, and if so, invalidate it in order to provide a PALB mechanism as seen by the LP. Such a hardware search machine is expensive, and as the size of the ALB increases, the number of processor cycles required to search it grows, thereby decreasing overall performance of the PALB algorithm.
In light of the above background, there is a need for an improved mechanism in order to preserve the logical integrity of the ALB across context switches.